Computer graphics processing systems process large amounts of data, typically with one or more graphics processing units (GPUs) performing most of the processing. A GPU produces the pixels that make up an image from a higher level description of its components in a process known as rendering. GPUs typically perform continuous rendering by using computing elements to process pixel, texture, and geometric data. The computing elements may execute the functions of rasterizers, setup engines, color blenders, hidden surface removal, and texture mapping. These computing elements are often referred to as shaders, shader processors, shader arrays, shader pipes, shader pipe arrays, shader pipelines, or a shader engine. “Shader” may also refer to an actual hardware component or processor used to execute software instructions (which is more accurately referred to as a “shader program”). A shader processor or program may read and render data and perform any type of processing of the data.
Much of the processing involved in generating complex graphics scenes involves texture data. Textures may be any of various types of data, such height map data, as image data, color or transparency data, roughness/smoothness data, reflectivity data, lookup tables, or other data. Textures may specify many properties, including surface properties like specular reflection or fine surface details in the form of normal or bump maps. Sometimes the term ‘texel’ is used in the art where a “texel” is a texture element in the same way a ‘pixel’ is a picture element. However, the terms ‘texel’ and ‘pixel’ are frequently used interchangeably (in that a “texel” is sometimes simply referred to as a “pixel”). Accordingly, either term may be used interchangeably within this disclosure.
Providing realistic computer graphics typically requires many high-quality, detailed textures. The use of textures, however, can consume large amounts of storage space and memory-to-GPU bandwidth, and consequently textures are normally compressed to reduce storage space and bandwidth utilization.
Texture compression has thus become a widely accepted feature of graphics hardware in general and 3D graphics hardware in particular. The goal of texture compression is to reduce storage and bandwidth costs on the graphics system while retaining as much of the quality of the original texture as possible. Many texture compression schemes use one of various block-based compression methods for encoding endpoints and interpolated pixel values, as is further described below. The Microsoft® BCn formats used in DirectX are examples of such schemes. It is desirable to develop ways to use these and other formats more flexibly to thereby permit encoding of new types of data (e.g., height map data) other than the data for which the formats were originally designed.
More specifically, new texture compression techniques take a long time to develop and deliver to the market in hardware form. During the transition time from one version of hardware based compression to the next, software developers produce new types of data requiring new compression techniques for which the existing compression schemes provide inadequate results. This creates a gap between the identification of these new techniques and the actual introduction of them to the market.
Accordingly, there exists a need for a method whereby custom data can be encoded using existing compression schemes and varied from block to block (rather than having global application across the entire image), to thereby provide new texture compression possibilities using existing hardware by allowing flexible hybrids of software and hardware based decoding techniques to be developed.